[SPIR-V] Add sampler & resource heaps for textures#8281
[SPIR-V] Add sampler & resource heaps for textures#8281Keenuts wants to merge 3 commits intomicrosoft:mainfrom
Conversation
|
CI failure is because of SPV tools update, requires #8278 |
Resource & Sampler heaps are already implemented in DXC, but rely on an emulated heap. A new VK/SPV extension bring actual descriptor heaps. This is the first step toward a complete support. This commits focuses on Texture/Sampler/Buffer resources, which are all backed by OpTypeImage/OpTypeSampler. This path is a bit simpler as we have no ArrayStride, nor OpAccessChain legalization issues: the whole image handle loading is handled in DXC, and the rest follows the normal path. Next step is to implement RWStructuredBuffer/StructuredBuffer support, with counters and chain legalization. Related to microsoft#8243
Keenuts
force-pushed
the
descriptor-heap
branch
from
068045c to
02fd8e2
Compare
|
Rebased on main now that SPV-tools fixes are merged. |
s-perron
left a comment
s-perron
left a comment
There was a problem hiding this comment.
Can you move the parts of the code that are not used (and therefore not tested) in this PR to the one where it is used?
I have a couple other ideas, but in general this is in good shape.
| def fspv_use_emulated_heap | ||
| : Flag<["-"], "fspv-use-emulated-heap">, | ||
| Group<spirv_Group>, | ||
| Flags<[CoreOption, DriverOption]>, | ||
| HelpText< | ||
| "Use emulated descriptor heap using descriptor indexing (default).">; | ||
| def fspv_use_descriptor_heap | ||
| : Flag<["-"], "fspv-use-descriptor-heap">, | ||
| Group<spirv_Group>, | ||
| Flags<[CoreOption, DriverOption]>, | ||
| HelpText<"Use SPV_EXT_descriptor_heap for HLSL descriptor heaps.">; |
There was a problem hiding this comment.
Why do you need two options?
There was a problem hiding this comment.
I was thinking about the migration for users:
- extension is brand new, we don't want to push it
- but long term, extension is better, so we want to encourage it.
Idea was to use the emulated by default for now, and in a future version, switch the default to use the extension, while allowing users to downgrade to emulation.
But no strong feeling about this.
There was a problem hiding this comment.
We let fspv-use-descriptor-heap default to false now. Then if we flip it, people can use fno-spv-use-descriptor-heap. Right?
If we have the two options, we have the odd situation: what if both are set to true or both are set to false?
| if (isa<ImageType>(type) || isa<SamplerType>(type) || | ||
| isa<AccelerationStructureTypeNV>(type)) | ||
| isa<AccelerationStructureTypeNV>(type) || isa<BufferEXTType>(type) || | ||
| isa<UntypedPointerKHRType>(type)) |
There was a problem hiding this comment.
For now, Untyped pointers will always be pointers to resources, but will this always be true? We may want to use untyped pointers for byte address buffers, which will be resources. We won't implement unions on DXC, so that will not be a problem. Any other situations?
There was a problem hiding this comment.
Not sure TBH, but does it matter? I suppose if we use them for something else we'll know what condition to change to refine this no?
| } | ||
| HeapVar = SamplerHeapVar; | ||
| } else | ||
| assert(0 && "Unsupported heap type"); |
| def fspv_use_emulated_heap | ||
| : Flag<["-"], "fspv-use-emulated-heap">, | ||
| Group<spirv_Group>, | ||
| Flags<[CoreOption, DriverOption]>, | ||
| HelpText< | ||
| "Use emulated descriptor heap using descriptor indexing (default).">; | ||
| def fspv_use_descriptor_heap | ||
| : Flag<["-"], "fspv-use-descriptor-heap">, | ||
| Group<spirv_Group>, | ||
| Flags<[CoreOption, DriverOption]>, | ||
| HelpText<"Use SPV_EXT_descriptor_heap for HLSL descriptor heaps.">; |
There was a problem hiding this comment.
We let fspv-use-descriptor-heap default to false now. Then if we flip it, people can use fno-spv-use-descriptor-heap. Right?
If we have the two options, we have the odd situation: what if both are set to true or both are set to false?
2 participants
Resource & Sampler heaps are already implemented in DXC, but rely on an emulated heap. A new VK/SPV extension bring actual descriptor heaps. This is the first step toward a complete support.
This commits focuses on Texture/Sampler/Buffer resources, which are all backed by OpTypeImage/OpTypeSampler. This path is a bit simpler as we have no ArrayStride, nor OpAccessChain legalization issues: the whole image handle loading is handled in DXC, and the rest follows the normal path.
Next step is to implement RWStructuredBuffer/StructuredBuffer support, with counters and chain legalization.
Related to #8243